Add E2E API client tests and update config

Populate ava-e2e.config.mjs env vars with dev API endpoint, scheme, and example client/server keys, and add new end-to-end tests and plan:

- e2e/api_client.ts: behavioral E2E tests for APIClient (getFeatureFlags, getSegmentUsers, getEvaluation).
- e2e/api_client_schema.ts: schema validation tests with composable assert helpers that verify presence and types of nested response fields (features, rules, strategies, segment users, evaluations, etc.).
- plan-addFieldPresenceAssertionsSchema.prompt.md: plan describing the bottom-up approach for adding field presence assertions and verification steps.

These changes add stricter schema checks to catch silent backend field removals and separate behavioral tests from schema validation.

Document API client schema tests

Add a header comment to e2e/api_client_schema.ts describing the test suite's purpose and approach. The comment explains that the tests perform deep, bottom-up schema validation of Bucketeer API responses—verifying presence and types of fields including nested objects and arrays—to catch breaking changes or field removals at the SDK level and prevent silent production failures. No functional code changes.

fix: schema checks and update Variation type

Use empty arrays instead of [''] in getSegmentUsers test calls, and adjust schema assertions to handle optional fields: cast allowed strings, only validate name/description when present, and make reason validation conditional. Also update Variation type to require id and name (make them non-optional) in src/objects/feature.ts. These changes fix false-positive test assumptions and align TypeScript types with expected runtime data.

Add rationale for runtime schema tests

Expand the header comment in e2e/api_client_schema.ts to explain why runtime schema tests are necessary: JSON.parse yields unknown/any at runtime and TypeScript types are erased at compile time, so a runtime test suite acts as the contract to catch backend field removals or type changes that could otherwise silently break production.

e2e: assert forceUpdate and segment users

Add assertions and clarifying comments to e2e/api_client.ts: ensure response.forceUpdate is true on initial getFeatureFlags and getSegmentUsers calls (so clients fetch latest data), and assert first.segmentUsers.length > 0 in the segment users test to guarantee a non-empty initial result. Minor formatting tweak.

Tighten featureFlagsId assertions in e2e test

Replace a loose inequality check with explicit assertions: verify featureFlagsId is a string and has length > 0. This makes the test more precise and ensures the response field is both the correct type and non-empty.